User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2372.0 Safari/537.36 Steps to reproduce: 0. In about:config, set layout.css.vertical-text.enabled to true 1. Open http://info.nicovideo.jp/indies-game-fest/history/ Actual results: 1. Parentheses are not properly rotated - i.e., vertical alternate glyphs are not used to render them - Not all, some are good. Probably parenthesis where following characters are Katakana are rendered correctly, but not sure (there is one instance that does not follow this rule.) 2. Some characters overwrap - Examples are the first vertical line in the lower column 3. Images are rotated counter-clockwise by 90 degrees Expected results: Note: IE, Safari, Chrome renders this page correctly.

Note Blink had an issue with this site, see https://crbug.com/470884

Note 2: harfbuzz incorporated the fix for the typesquare fonts at: https://github.com/behdad/harfbuzz/commit/0f98fe88f42471eb8fb28d08d45eca9cd8303f7a

Parentheses are not properly rotated. Is this still happening with the latest nightly (52.0a1) or stable release (49.0.2) of Firefox? Eg While using Firefox 49.0.2 under Linux, each and all parentheses ( "(", ")", U+300C LEFT CORNER BRACKET "「", U+300D RIGHT CORNER BRACKET "」") are rotated 90 degrees clock-wise, as expected. If so, then would it be possible to create a reduced test demonstrating this? - - - - - - - Some characters overwrap. I do see some characters overlap with Firefox 49.0.2 but the style sheet screen.css http://info.nicovideo.jp/indies-game-fest/history/styles/css/screen.css alone has 327 rules and 2005 lines of code (minified on top of everything!). Ideally, we would need a reduced test demonstrating how this happens. style sheet screen.css also uses vendor-prefix -webkit which Firefox does not support. Eg '-webkit-text-orientation: upright' at line 335 of unminified screen.css will be resolved as 'text-orientation: mixed' by Firefox. - - - - - - - Images are rotated counter-clockwise by 90 degrees. Yes, I see at least 1 image rotated but the wrapping div has this rule: #rollBoxInner > section.section.section03.sectionContents > div.sectionCross.sectionCrossV.sectionCrossVfirst > div.sectionBtm.sectionPos > div > div { ... -webkit-text-orientation: vertical-right; } So, at first sight, this does not seem to be caused by a Firefox bug but rather related to unsupported -webkit vendor-prefix Again, best would be to have a reduced test demonstrating such issue, how this happens and why there is an incorrect implementation.

> div.sectionBtm.sectionPos > div > div > { > ... > -webkit-text-orientation: vertical-right; > } It should have been written -webkit-writing-mode: vertical-right; instead. - - - - - - - Here's proof and demonstration that -webkit vendor-prefix affect how japanese text can be rendered (orientation and layout) : http://www.gtalbot.org/BugzillaSection/Bug1155980-vertical-glyphs-not-rendered.xhtml You need to load that test in Firefox latest stable release (49.0.2 as of today) and in Chrome latest stable release (version 54.0.2840.71 as of today)

When you compare Firefox and Chrome rendering of http://www.gtalbot.org/BugzillaSection/Bug1155980-vertical-glyphs-not-rendered.xhtml there are a lot of differences in terms of glyph orientation, glyph layout and shape and also line breaking.

> 3. Images are rotated counter-clockwise by 90 degrees For an unknown (to me!) reason, this rule (at line 1892, once the screen.css style sheet is unminified) #rollBox .sectionContents .sectionCrossV .sectionPos .fusen { top:auto !important; right:auto !important; bottom:65px !important; left:0 !important; -webkit-transform:rotate(-90deg); -moz-transform:rotate(-90deg); -ms-transform:rotate(-90deg); -o-transform:rotate(-90deg); transform:rotate(-90deg); -moz-transform-origin:100% 100% !important; z-index:2 } /* a=0 b=1 c=4 d=0 -> specificity = 0,1,4,0 but latter specified wins */ is not honored, is ignored or seems ignored by Chrome 54 while it is honored and is not ignored in Firefox 49.0.2. Chrome 54 does honor (at line 565, once the screen.css style sheet is unminified) #rollBox .sectionContents .sectionCrossV .fusen_p_type6 .fusen { top: 0; right: 10px; -webkit-transform: rotate(4deg); -moz-transform: rotate(4deg); -ms-transform: rotate(4deg); -o-transform: rotate(4deg); transform: rotate(4deg); } /* a=0 b=1 c=4 d=0 -> specificity = 0,1,4,0 but not the last in code order */ I spent over 2 hours now on the webpage http://info.nicovideo.jp/indies-game-fest/history/ and I have given up on trying to figure out why images are not rotated counter-clockwise by 90 degrees in Chrome 54. - - - - - - In conclusion: unless we can create a reduced test demonstrating an implementation bug, a spec violation in Firefox, I have strong reasons to believe that this bug report is INVALID.